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DETAILED ACTION 

A new Examiner has been assigned to this application. 



This office action is in response to Applicant's request for request for continued 
examination on 8/29/05. Claims 1-50 are presented for further examination. 



Priority 

1. Applicant claims priority to provisional application 60/212,979, filed 6/21/2000. 

2, The effective filing date for the subject matter defined in the pending claims in this 
application is 6/21/2000. 



Information Disclosure Statement 
3. It is noted that the Applicant failed to submit an IDS. 



Claim Rejections - 35 USC §102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this 
or a foreign country, before the invention thereof by the applicant for a patent. 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
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subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 2 1 (2) of such treaty in the English language. 

4. Claims 1-4, 9-10, 12-20, 25-26, 28-37, 39, 41, 44-47 are rejected under 35 U.S.C. 102(a) 
as being anticipated by John et al. (XNAMI - An extensible XML-based paradigm for 
Network and Application Management Instrumentation; hereinafter John). 

It is noted for the record that the John reference was previously cited in PTO-892 as 
document U, on 9/30/2003. 

With regard to claims 1, 3-4, 9, 17, 19-20, 25, 33, and 36-37 John disclosed a method for 
controlling a data forwarding service in a network device comprising a data forwarding device, 
comprising the steps of: 

Receiving at the network device (e.g. a router, see Introduction Col 1), a document 
written in accordance with a markup language (description in XML of new objects, pg 5 Col 2 
bullet number 1 and pg 7 last 1J Col 1 - discussion of SET commands to add new objects) and a 
corresponding document definition (XML DTD, pg 4, Col 1), wherein the document describes 
the data forwarding service (e.g. routing functionality for a router); 

Parsing by the network device the received document in accordance with the 
corresponding document definition, wherein the parsing determines at least one parameter 
describing the data forwarding service (pg 7 Col 1 last % parsing description of new objects); and 

parsing from the document an identifier corresponding to the service (e.g. Figure 7, MIB 
object name) 
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Executing the data forwarding service (the associated object instances for the desired 
functions; e.g. routing in the case of a router, see Introduction Col 1, also note the device may 
forward any monitoring information, see for instance pg 8, Col 2) on the network device upon 
completion of the parsing, in accordance with the parsed document, and wherein the executing 
includes instantiating and launching the data forwarding service in the data forwarding device 
(pg 7, Col 2 1 st % instantiating and running the new MIB objects, for further explanation of 
runtime representation refer to pg 6 of section 4.1). 

With regard to claims 2 and 18, John disclosed the means for executing including means 
for interfacing with hardware and software on the network device (Figure 5, Agent architecture). 

With regard to claims 10, 12, 26, and 28, John disclosed means for parsing from the 
document runtime parameters corresponding to the service (pg 7 Col 1, last U - value to set) and 
instantiating an object corresponding to the service in accordance with the parsed identifier and 
the parsed runtime parameters (pg 7, Col 2, 1 st fl). 

With regard to claims 13-14, 29-30, 41, John disclosed the network device comprises one 
of a router, a switch, and a hub, wherein the network device comprises a packet forwarding 
architecture (e.g. a router, see Introduction Col 1). 

With regard to claims 15-16 and 31-32, John disclosed preparing a response 
corresponding to the executed service and forwarding the response to a remoter requestor of the 
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service (e.g. requested monitoring information, pg 8, Col 2; also may be interpreted as simply 
routing requested data in the case of a router). 

With regard to claim 34, John disclosed a network data transfer service that is adapted to 
communicate with remote devices for receiving the document (SNMP stack, see for instance 
Figure 5 where the manager transfers files to the agent through SNMP PDUs Figure 8). 

With regard to claim 35, John disclosed the network data transfer service comprises an 
HTTP server (pg 5, last sentence of the 1 st ft). 

With regard to claim 39, John disclosed a services storage coupled to the service launcher 
that stores a plurality of services (MIB tree of objects), the service launcher being further adapted 
to select the service from the stored plurality of services in accordance with the parsed identifier 
(instantiate MIB objects, pg 7, Cols 1 and 2). 

With regard to claim 44, John disclosed the launched service accesses a MIB on the 
network device (Section 4. 1, XNAMI MIB). 

With regard to claims 45 and 47, John further discloses device APIs for interoperating 
with the device hardware and software for executing launched services (Java based objects and 
associated instances, John pg 6, Cols 1 and 2 of Section 4. 1). 
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Claim Rejections - 35 USC §103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 5-8, 11, 21-24, 27, 38, and 48-50 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over John et al. (XNAMI - An extensible XML-based paradigm for 
Network and Application Management Instrumentation; hereinafter John) and Bryan (An 
Introduction to the Extensible Markup Language XML). 

With regard to claims 48-50, John disclosed a method for causing a network device to 
locally perform a service, comprising the steps of: 

Identifying the service (e.g. adding a new MIB objects to run) to be performed at a 
remote client computer (XNAMI manager issues the SET command), and preparing at the 
remote client computer a document written in a markup language (description in XML of the 
new object) in accordance with a document definition (XML DTD, pg 4, Col 1), the document 
including an identifier of the service (e.g. MIB object name) (see pg 5 Col 2 bullet number 1 and 
pg 7 last U Col 1 - discussion of SET commands to add new objects); 

Transmitting the document to the network device (XNAMI sends the SET command, see 
Figure 8 for contents and pg 8 Col 1, 1 st If); 
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Identifying at the network device the document definition corresponding to the 
transmitted document 0; 

Parsing by the network device the transmitted document in accordance with the 
corresponding document definition (pg 7 Col 1 last 1J, parsing description of new objects); 

and 

Executing the service on the network device in accordance with the parsed document (pg 
7, Col 2 1 st % instantiating and running the new MIB objects, for further explanation of runtime 
representation refer to pg 6 of section 4. 1). 

John disclosed the invention substantially as claimed, however John did not explicitly 
recite identifying at the network device the document definition corresponding to the transmitted 
document. Nevertheless the agent in John's system must be able to properly interpret the sent 
XML document (description in XML of the new object pg 7 last ^ Col 1). Further, John 
disclosed that the transmitted XML document is defined by a document definition (DTD) (John 
pg 4, Col 1). John did not further discuss the well known use of XML and DTDs within XML 
instead, motivating the reader to seek out more descriptive teachings outlining DTDs and XML 
at the SGML/XML web page ( www. oasis-open. org/co ver/sgml-xml . html ) (John pg 4). In an 
introduction to XML document available at the SGML/XML webpage dating back to at least 
1997, Bryan disclosed that XML coded text identifies corresponding DTDs either within the 
XML document itself (i.e. inline) or alternatively through a link contained within the XML 
document pointing to a DTD file (i.e. by reference) (Bryan, pg 6 - #2). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to incorporate the XML 
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DTD identification, as disclosed by Bryan, within the XML file transmitted to the network 
device agents in John's system, so that the device agent is able to identify the appropriate DTD 
for that XML file (Bryan, pg 6). 

With regard to claims 5-8, 21-24, 38, a similar rationale is used for the combination of 
John and Bryan as applied to claim 48. As discussed above Bryan disclosed identifying a 
document definition through an identifier (document type declaration Bryan, pg 6 - #2), which is 
used by the parser (XML processor) to associate the XML file with the corresponding XML 
DTD (Bryan pg 6). However neither John nor Bryan disclosed storing a plurality of document 
definitions locally. Nevertheless, it was well known in the art at the time of the invention to 
store XML DTDs a device needs locally. Thus, it would have been obvious to one of ordinary 
skill in the art at the time of the invention to store a plurality of DTDs locally at the agents 
disclosed by John, within the combined John and Bryan system, so that DTDs referenced in the 
received XML files would be readily available. 

With regard to claim 1 1 and 27, John disclosed instantiating an object corresponding to 
the service in accordance with the parsed identifier (pg 7, Col 2, 1 st U). 

6. Claims 40 and 46 are rejected under 35 U.S.C. 103(a) as being unpatentable over John et 
al. (XNAMI - An extensible XML-based paradigm for Network and Application 
Management Instrumentation; hereinafter John) and in view of Applicant's admission of 
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the prior art, or alternatively in view of Jaeger et al. (Dynamic Classification in Silicon- 
based Forwarding Engine Environments, December 1999, hereinafter "Jaeger"). 

In considering claim 40, John teaches that the service launcher is adapted to launch the 
service using a runtime environment (java based objects and associated instances, John pg 6, 
Cols 1 and 2 of Section 4. 1). However, John does not disclose the use of the "Oplet Runtime 
Environment." Nonetheless, the Oplet Runtime Environment is a well-known environment in 
the router environment, as evidenced by both Applicant's admission of prior art (see 
specification, p. 9, lines 8-16), and by Jaeger (Abstract). A person having ordinary skill in the art 
would have readily recognized the desirability and advantages of using the ORE to manage the 
routers in the system taught by John because ORE "supports the creation of services in Java that 
are extensible, portable, and easily distributed over the network," (see Jaeger, Conclusion, p. 
109). Thus, it would have been obvious to use the Oplet Runtime Environment as the runtime 
environment in the system taught by John. 

In considering claim 46, John further discloses device APIs for interoperating with the 
device hardware and software for executing launched services (Java based objects and associated 
instances, John pg 6, Cols 1 and 2 of Section 4. 1). 
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7. Claims 42 and 43 are rejected under 35 U.S.C. 103(a) as being unpatentable over John et 
al. (XNAMI - An extensible XML-based paradigm for Network and Nilakantan et al. 
(U. S. Patent Number 5,54 1,911; hereinafter Nilakantan). 

With regard to claims 42 and 43, John disclosed controlling and monitoring (any variable 
in the MIB can be monitored pg 8, Col 2) networking devices (for instance routers, introduction 
Col 1) by manipulating the network devices MIB remotely (see inter alia, sections 4. 1 and 4.2) 
however, John failed to specifically recite changing how packets are forwarded through the 
packet forwarding switch fabric and monitoring performance indicators of how packets are 
forwarded through the packet forwarding switch fabric. Nevertheless it was well known in the 
art at the time of the invention that MIBs within networking devices (routers) are used to control 
how packets are forwarded through the router packet forwarding switch fabric, as evidenced by 
Nilakantan. In an analogous art, Nilakantan disclosed manipulating an MIB within a router 
through SNMP commands in order to change how packets are forwarded through the packet 
forwarding switch fabric (Nilakantan Col 5, line 61- Col 6, line 9). Thus, it would have been 
obvious to one of ordinary skill in the art at the time of the invention to extend John's MIB 
modification and monitoring system to include an MIB which configures and monitors how 
packets are forward within a router, given that John's system was meant to be dynamically 
configured to work with any networking device including routers (John introduction) and further 
such remote control allows administrators to remotely configure networks (Nilakantan Col 3, 
lines 44-53). 
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1. Claims 1-4, 9-20, 25-37, 39, 41-43, 45, and 47-50 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Humpleman et al. (U.S. Patent No. 6,546,419, hereinafter 
"Humpleman"), in view of Duffy ("HP Intros Mgmt Apps for Router Nets, from 
Network World, 1994), and further as supported by Weschler, Jr. (U.S. Patent No. 
6,757,720, hereinafter "Weschler"). 

In considering claim 1, Humpleman discloses a method for controlling a service in a 
network device ("device B"), comprising the steps of: 

receiving at the network device a document written in accordance with a markup 
language ("interface document INTERFACE. XML") and a corresponding document definition 
("document type definition INTERFACE. DTD") (col. 15, lines 44-52; col. 18, lines 8-11, "the 
XMLRPC command messages are sent to the controlled device B over the network. Upon 
receiving said XMLRPC command messages..."), wherein the document describes a service 
(col. 18, lines 12-16, "requested services"); 

Means for parsing by the network device upon completion of the parsing the received 
document in accordance with the corresponding document definition and wherein the executing 
includes instantiating and launching the data forwarding service in the data forwarding device 
(col. 18, lines 1 1-13, "the controlled application 84 of device B uses the XML parser 74 of 
device B to parse and interpret the received XML command messages"); 

Means for executing the service on the network device in accordance with the parsed 
document (col. 18, lines 14-17, "device B then decodes the parser results... to perform requested 
services"). 
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However, Humpleman does not disclose that the service, device, and document relate to 
data forwarding, such that the document causes data forwarding services to be performed. 
Instead, Humpleman teaches using the above technique for controlling client/server services on a 
home network. 

Nonetheless, it is well known to remotely control and manage not only home devices on a 
home network, but also routing devices on a routing network, as evidenced by Duffy. Duffy 
discloses that as far back as 1994, network applications were able to control and manage 
forwarding services on routers over a network ("from this PC, users can assign addresses, check 
for duplicate addresses and errors, use point-and-click commands to Connect' routers. . . and 
validate configuration parameters for all routers," U 3; "configuration files stored in a central file 
server and manually uploaded to the server and management station, and downloaded to 
AdvanceStack routers," ^ 4). Furthermore, it is well known to control and manage such devices 
using XML, as evidenced by Weschler (col. 9, line 67 - col. 10, line 3, "Routers, switches, 
network ports, and other network devices recognize XML formatted documents embedded in 
HTTP data transport packets and are configured to handle them appropriately and reliably"). 

Given the teaching of Duffy and Weschler of using XML to control network routers, a 
person having ordinary skill in the art would have readily recognized the desirability and 
advantages of using the particular XML remote management document, definition, and parsing 
method taught by Humpleman to control network routers using XML, because XML is "well 
understood, actively developed, and readily transportable through a variety of communications 
media," (Weschler, col. 9, lines 63-65) and would thus allow comprehensive management of 
network routers with few development costs. 
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In considering claim 17, Humpleman discloses a network device ("device B") for locally 
performing a data forwarding service in response to a remote request, comprising: 

Means for receiving at the network device a document written in accordance with a 
markup language ("interface document INTERFACE. XML") and a corresponding document 
definition ("document type definition INTERFACE.DTD") (col. 15, lines 44-52; col. 18, lines 8- 
11, "the XMLRPC command messages are sent to the controlled device B over the network. 
Upon receiving said XMLRPC command messages..."); 

Means for parsing by the network device the received document in accordance with the 
corresponding document definition (col. 18, lines 11-13, "the controlled application 84 of device 
B uses the XML parser 74 of device B to parse and interpret the received XML command 
messages"); 

Means for executing the service on the network device upon completion of the parsing in 
accordance with the parsed document, wherein the executing includes instantiating and 
launching the data forwarding service in the data forwarding device (col. 18, lines 14-17, "device 
B then decodes the parser results, . . to perform requested services"). 

However, Humpleman does not disclose that the service, device, and document relate to 
data forwarding, such that the document causes data forwarding services to be performed. 
Instead, Humpleman teaches using the above technique for controlling client/server services on a 
home network. 

Nonetheless, it is well known to remotely control and manage not only home devices on a 
home network, but also routing devices on a routing network, as evidenced by Duffy. Duffy 
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discloses that as far back as 1994, network applications were able to control and manage 
forwarding services on routers over a network ("from this PC, users can assign addresses, check 
for duplicate addresses and errors, use point-and-click commands to 'connect 5 routers... and 
validate configuration parameters for all routers/ 1 U 3; "configuration files stored in a central file . 
server and manually uploaded to the server and management station, and downloaded to 
AdvanceStack routers," ^ 4). Furthermore, it is well known to control and manage such devices 
using XML, as evidenced by Weschler (col. 9, line 67 - col. 10, line 3, "Routers, switches, - 
network ports, and other network devices recognize XML formatted documents embedded in 
HTTP data transport packets and are configured to handle them appropriately and reliably"). 

Given the teaching of Duffy and Weschler of using XML to control network routers, a 
person having ordinary skill in the art would have readily recognized the desirability and 
advantages of using the particular XML remote management document, definition, and parsing 
method taught by Humpleman to control network routers using XML, because XML is "well 
understood, actively developed, and readily transportable through a variety of communications 
media," (Weschler, col. 9, lines 63-65) and would thus allow comprehensive management of 
network routers with few development costs. 

In considering claims 2 and 18, Humpleman further discloses the means for executing 
including means for interfacing with hardware and software on the network device (col. 15, lines 
11-15, "in each device 14, applications at the top of the communication stack send and receive 
communication messages over the network, and communicate with software layers in the device 
stack that locally control the device hardware or service software for the device"). 
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In considering claims 3 and 19, Humpleman further discloses that the markup language is 
XML ("XML"). 

In considering claims 4 and 20, Humpleman further discloses that the corresponding 
document definition is an XML DTD ("DTD"). 

In considering claims 9 and 25, Humpleman further discloses that the means for parsing 
include means for parsing from the document an identifier ("method name") corresponding to 
the service (col. 18, lines 13-17). 

In considering claims 10 and 26, Humpleman further discloses that the means for parsing 
include means for parsing from the document runtime parameters corresponding to the service 
(col. 12, lines 63-65, "the look-up 56 table provides run-time translation of XML object method 
calls from Service B into device native language calls for Service A"). 

In considering claims 1 1 and 27, Humpleman further discloses means for instantiating an 
object corresponding to the service in accordance with the parsed identifier (col. 18, lines 19-21, 
"launch the native function implementations of device B"). 

In considering claims 12 and 28, Humpleman further discloses means for instantiating an 
object corresponding to the service in accordance with the parsed identifier and the parsed 
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runtime parameters (col. 18, lines 19-21, "launch the native function implementations of device 
B," col. 12, lines 60-65, "run-time translation of XML object method calls"). 

In considering claims 13 and 29, both Weschler and Duffy further disclose that the 
network can be one of a multitude of devices, including a router. 

In considering claims 14 and 30, both Weschler and Duffy further disclose that the 
network device comprises a packet forwarding architecture (i.e. a router). 

In considering claims 15 and 31, Humpleman further discloses means for preparing a 
response corresponding to the executed service (col. 18, lines 21-24, "responses"). 

In considering claim 16 and 32, Humpleman further discloses means for forwarding the 
response to a remote requestor of the service (col. 18, lines 23-24, "responses [are] sent to the 
controller device A"). 

In considering claim 33, Humpleman discloses a network device ("device B") for locally 
performing a service in accordance with a received document written in a document markup 
language ("interface document INTERFACE. XML"), comprising: 

Means for receiving at the network device a document written in accordance with a 
markup language ("interface document INTERFACE. XML") and a corresponding document 
definition ("document type definition INTERFACE.DTD") (col. 15, lines 44-52; col. 18, lines 8- 
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11, "the XMLRPC command messages are sent to the controlled device B over the network. 
Upon receiving said XMLRPC command messages. . ."); 

A parser that is adapted to parse the received document in accordance with the 
corresponding document definition to obtain an identifier of the service (col. 18, lines 11-16, 
"the controlled application 84 of device B uses the XML parser 74 of device B to parse and 
interpret the received XML command messages," wherein the identifier is the "method name"); 
and 

A service launcher that is adapted to launch the service corresponding to the identifier 
parsed from the received document wherein the executing includes instantiating and launching 
the data forwarding service in the data forwarding device (col. 18, lines 17-21, "device B then 
uses the XML. . . to access and launch the native function implementation of device B . ."). 

However, Humpleman does not disclose that the service, device, and document relate to 
data forwarding, such that the document causes data forwarding services to be performed. 
Instead, Humpleman teaches using the above technique for controlling client/server services on a 
home network. 

Nonetheless, for the same reasons already discussed with regard to claims 1 and 17, it 
would have been obvious to use the Humpleman XML remote management document, 
definition, and parsing method taught by Humpleman to control data forwarding services on a 
network. 

In considering claim 34, Humpleman further discloses a network data transfer service 
that is adapted to communicate with remote devices for receiving the document (col. 16, lines 
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13-16, "a Home Network Device Web server 86 in each of the devices A and B manages 
communication between the devices over the network"). 

In considering claim 35, Humpleman further discloses that the network data transfer 
service comprises an HTTP server ("Web server 86"). 

In considering claim 36, Humpleman further discloses that the markup language is XML 
("XML"). 

In considering claim 37, Humpleman further discloses that the corresponding document 
definition is an XML DTD ("DTD"). 

In considering claim 39, Humpleman further discloses a services storage coupled to the 
service launcher that stores a plurality of services, the service launcher being further adapted to 
select the service from the stored plurality of services in accordance with the parsed identifier 
(col. 18, lines 9-21, wherein the parsing obtains method call information and a method name, 
which are used to select from the plurality of services - i.e. handlers - to perform the service). 

In considering claim 41, Weschler and Duffy both disclose that the device further 
comprises a packet forwarding switch fabric (i.e. "routers," and "switches"). 



Application/Control Number: 09/692,949 Page 19 

Art Unit: 2153 

In considering claim 42, Weschler farther discloses that the launched service causes 
changes in how packets are forwarded through the switch fabric (i.e. assigning addresses and 
connecting routers causes changes in how packets are forwarded through the switch fabric). 

In considering claim 43, Weschler further discloses that the management system can also 
monitor performance of packet forwarding in the routers (p. 2, 2, "Traffic Monitor lets network 
managers analyze traffic patterns on all LAN segments and wide-area links from a single 
Windows PC or Unix workstation"). 

In considering claim 45, Humpleman further discloses device APIs for interoperating 
with the device hardware and software for executing launched services (col. 14, lines 20-25, 
"API interface"). 

In considering claim 47, Humpleman further discloses device APIs for interoperating 
with the device hardware and software for executing launched services (col. 14, lines 20-25, 
"API interface"). 

In considering claim 48, Humpleman discloses a method for causing a network device to 
locally perform a service, comprising the steps of: 

Identifying the service to be performed at a remote client computer, and preparing at the 
remote client computer a document written in a markup language in accordance with a document 
definition, the document including an identifier of the service (col. 18, lines 3-10, wherein 
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"device A" generates the XML document to send a command message to device B, the document 
inherently including an identifier of the service - see Example 1, line 45, wherein 
U D VCR 1. record" identifies the service); 

Transmitting the document to the network device (col. 18, lines 8-9); 

Identifying at the network device the document definition corresponding to the 
transmitted document (col. 18, lines 10-16; col. 15, lines 44-52, wherein the DTD file 
corresponding to the document is also received and identified at the network device); 

Parsing by the network device the transmitted document in accordance with the 
corresponding document definition (col. 18, lines 10-16, "parse and interpret the received XML 
command messages"); and 

Executing the service on the network device upon completion of the parsing in 
accordance with the parsed document wherein the executing includes instantiating and launching 
the data forwarding service in the data forwarding device (col. 18, lines 12-17, "perform 
requested services"). 

However, Humpleman does not disclose that the service, device, and document are 
related to a data forwarding service. Nonetheless, for the same reasons already discussed with 
regard to claims 1 and 17, it would have been obvious to use the Humpleman XML remote 
management document, definition, and parsing method taught by Humpleman to control data 
forwarding services on a network. 

In considering claim 49, Humpleman further discloses that the markup language is XML 
("XML"). 
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In considering claim 50, Humpleman further discloses that the corresponding document 
definition is an XML DTD ("DTD"). 

2. Claims 5-8, 21-24, and 38 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Humpleman, in view of Weschler and Duffy, and further in view of Gessner (U.S. Patent 
Publication No. 2002/0032709, filed on Sep. 29, 1998). 

In considering claims 5, 7, 21, and 23, these claims all recite retrieving the corresponding 
document definition from a plurality of document definitions in accordance with an identifier in 
the received document. Humpleman teaches a document definition corresponding to a 
document, but remains silent regarding how the document definition is selected or retrieved. 
Nonetheless, selection at run time of document definitions that correspond to a selected markup 
language document is well known, as evidenced by Gessner. Gessner discloses a system that 
uses DTDs and their corresponding documents, wherein the DTDs "may be locally stored [or] 
may be stored remotely on server systems and delivered at and during run time of a browser, etc. 
to facilitate dynamic replacement of particular grammars and to further facilitate the rendering of 
content based thereon." See ^ [0041]. Thus, a person having ordinary skill in the art would have 
readily recognized the desirability and advantages of selecting the corresponding DTDs in the 
system taught by Humpleman, Weschler, and Duffy according to the id contained in the 
documents, to facilitate dynamic creation of the XML file, thereby further enhancing the 
dynamic nature of the control and command system taught by Humpleman, Weschler, and Duffy 
(see Humpleman, col. 2, lines 39-41). Therefore, it would have been obvious to use the dynamic 
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DTD selection taught by Gessner in the dynamic control and command system taught by 
Humpleman, Weschler, and Duffy. 

In considering claims 6, 8, 22, and 24, Gessner further discloses that the document 
definitions are provided locally ([0041], "DTD components may be locally stored"). 

In considering claim 38, claim 38 contains the same limitations as claims 5, 7, 21, and 23, 
but adds the feature that the device further comprises a document definition storage that stores 
the plurality of definitions from which selection is made. This storage feature is further taught 
by Gessner in ^ [0041], which recites "DTD components may be locally stored." 

3. Claims 40 and 46 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

Humpleman, Weschler, and Duffy, in view of Applicant's admission of the prior art, or 
alternatively in view of Jaeger et al. (Dynamic Classification in Silicon-based Forwarding 
Engine Environments, December 1999, hereinafter "Jaeger"). 
In considering claim 40, Humpleman teaches that the service launcher is adapted to 
launch the service using a runtime environment (col. 18, lines 10-21 describe that the service 
launcher generates native function implementations from the XML document, and col. 12, lines 
55-65 describe that such translation occurs at run-time). However, Humpleman does not 
disclose the use of the "Oplet Runtime Environment." Nonetheless, the Oplet Runtime 
Environment is a well-known environment in the router environment, as evidenced by both 
Applicant's admission of prior art (see specification, p. 9, lines 8-16), and by Jaeger (Abstract). 
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A person having ordinary skill in the art would have readily recognized the desirability and 
advantages of using the ORE to manage the routers in the system taught by Humpleman, 
Weschler, and Duffy because ORE "supports the creation of services in Java that are extensible, 
portable, and easily distributed over the network," (see Jaeger, Conclusion, p. 109). Thus, it 
would have been obvious to use the Oplet Runtime Environment as the runtime environment in 
the system taught by Humpleman, Weschler, and Duffy. 

In considering claim 46, Humpleman further discloses device APIs for interoperating 
with the device hardware and software for executing launched services (col. 14, lines 20-25, 
"API interface"). 

4. Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Humpleman, 
Weschler, and Duffy, in view of Dobbins et al. (U.S. Patent No. 5,951,649, hereinafter 
"Dobbins"). 

In considering claim 44, although the system taught by Humpleman, Weschler, and 
Duffy discloses substantial features of the claimed invention, it fails to disclose that launched 
service accesses a MIB on the network device. Nonetheless, Duffy discloses changing router 
configuration by altering 'connections' between routers. Furthermore, as shown by Dobbins, it 
is well known that one way to represent connections between routers and other forwarding 
functions is through a MIB (col. 6, lines 41-55). Thus, given this knowledge, it would have been 
obvious to alter the router connections in the system taught by Humpleman, Weschler, and Duffy 
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by altering a MIB, because a MIB structure can be easily changed and understood by an 
administrator (see Dobbins, col. 6, lines 52-55). 



Response to Arguments 
8. In response to Applicant's request for reconsideration filed on 8/29/05, the following 
factual arguments are noted: 

a. The combination of Humpleman,, Duffy, and Weschler is improper. 

b. Humpleman does not disclose a data forwarding device or service. 

c. Humpleman failed to disclose various new limitations. 

In considering (a), Examiner respectfully disagrees with Applicant's argument. The 
combination of Humpleman, Duffy, and Weschler is clearly proper. Applicant is reminded that 
obviousness can be established by combining or modifying the teachings of the prior art to 
produce the claimed invention where there is some teaching, suggestion, or motivation to do so 
found either in the references themselves or in the knowledge generally available to one of 
ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/w 
re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In the instant case, a clear 
motivation was set forth directly from the references themselves. 

In considering (b), Examiner respectfully disagrees with Applicant's argument. Such an 
argument is completely irrelevant given that Humpleman was not even cited to teach such. It is 
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clear that Applicant has interpreted a data forwarding device to be only a router or equivalent 
thereof. The terms "data forwarding device" and "data forwarding service" are extremely broad 
and read on virtually any device which outputs information in some form. If Applicant intends 
to claim only a routers then the Applicant should make an appropriate amendment limiting the 
independent claims to only routers. 

In considering (c), Examiner respectfully disagrees with Applicant's argument. Based on 
Applicant's arguments and a discussion with Applicant in an interview 9/13/05 Applicant 
contends that the XML device interface file sent from a controlled device (i.e. Device B in 
Humpleman Col 18, lines 3-4) to a controlling device (i.e. Device A in Humpleman Col 18, lines 
3-4) is parsed and invokes a service in device A to control device B through RPC calls. The 
Examiner respectfully disagrees with this interpretation of the current rejection set forth. Rather 
the current rejection set forth by the Examiner shows the parsed file of Applicant's claimed 
invention to be the XMLRPC command message of Humpleman. Wherein the controlling 
device A sends an XML message (XMLRPC) commanding the controlled device B to instantiate 
and launch a service after parsing the XML message command (Col 18, lines 1-17). 

Conclusion 

The previous grounds of rejection set forth on 4/27/05 stands as set forth above. A new 
grounds of rejection has also been added. All claims stand rejected with no allowable subject 
matter identified. It is noted that Applicant's claimed invention is still extremely broad. In 
considering the independent claims a simple web browser downloading, parsing, and displaying 
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an XML web document would read on the independent claims with the broad terms "data 
forwarding" used to describe the device and service. The cited and applied John reference 
substantially embraces the sprit and scope of Applicant's claimed invention and disclosure. 

9. The prior art made of record, in PTO-892 form, and not relied upon is considered 
pertinent to applicant's disclosure. 

10. This office action is made NON-FINAL. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sean Reilly whose telephone number is 571-272-4228. The 
examiner can normally be reached on M-F 8-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess can be reached on 571-272-3949. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 





